【初データレイク体験】AWS Loft Osakaで DataLake ハンズオンを受けてきた(公開資料URLあり)

【初データレイク体験】AWS Loft Osakaで DataLake ハンズオンを受けてきた(公開資料URLあり)

Clock Icon2019.10.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大阪オフィスのちゃだいんです。

本日はAWS Pop-Up Loft Osakaにて、ハンズオンに参加してきました。

今回はそのハンズオンの内容をご紹介したいと思います。

その前に、

AWS Pop-Up Loft Osakaは期間限定でオープンしており、本日が最終日でした...(涙)

大阪のど真ん中一等地に、無料でコーヒーももらえるコワーキングスペース。中之島の高層ビル26階からの眺めを楽しみながら、優雅にパソコンパチパチできる稀有な場所でした。

どんな場所だったのかは、このブログをご覧ください。

【AWS Loftが大阪に期間限定オープン!】オープンしたてのAWS Pop-Up Loft Osakaで早速リモートワークしてみた #awsloft

ハンズオン概要

DataLake ハンズオン OCT 31,2019

About the event(上記ページより抜粋)

幅広いデータソースからの構造化データまたは非構造化データの集中リポジトリとして活用できるデータレイクは、膨大な量のデータの蓄積とアドバンスな分析を実現するプラットフォームとして多くの企業に取り入れられています。 当セミナーでは、AWSにおけるビッグデータ分析の考え方を座学形式で学んでいただいた後、下記AWS アナリティクスサービスを使った分析パイプラインの構築を通して、「データレイク」と「ビッグデータ分析基盤の構築」を実際にご参加者に体験いただくことをゴールとしています。

タイムテーブル

  • 10:30 受付
  • 10:50 座学
  • 11:20 ハンズオンスタート
  • 16:30 ハンズオン終了

冒頭に30分程度座学があり、その後にもらった資料をもとにもくもくハンズオンという構成でした。

ハンズオン公開資料URL

なんと、今回のハンズオン資料一式が、Githubにて公開されてます。 なので、どなたでも実際にハンズオンで行った内容をやっていただくことが可能です。

ぜひ興味のある方は、一度試してみてください。

GithubURL <aws-samples/amazon-s3-datalake-handson>

ハンズオンをやるにあたって

どんなことをするの?

  • 擬似的なアプリケーションログを対象に分析を行います
  • ラムダアーキテクチャを実装し、リアルタイムの可視化と、オンデマンドでのアドホッククエリを行います

ハンズオンのやり方3パターン

当ハンズオンは全部で6つのセクションに分かれています。

  • ニアリアルタイムの処理をする環境(1. 2. 3.)
  • 長期間のデータをバッチ分析する環境(1. 4. 5. 6.)

やりたい内容やボリュームによってやり方を変えられます。「サクッとリアルタイム処理をやりたい!」の場合は、1.2.3、「ETL処理とかバッチ分析やりたい!」の場合は、1.4.5.6、「両方やりたい!!!!」の場合は、1.2.3.4.5.6という順番で行うことができます。

各セクション概要

  1. EC2にFluentdをインストールする
  2. アプリケーションログをリアルタイムで可視化:Elasticsearch Service(Kibana) を入れる
  3. CloudWatchを入れてリアルタムログ監視を行う
  4. ストリーミングデータを直接データストアに永続化し、アドホックな分析を行い、BIツールで可視化する
  5. 同じS3のデータを、Redshift Spectrum に読み込み分析し、BIツールで可視化する
  6. Glueを使用してデータのETL処理をサーバレスで行う

おまけ:なぜETL処理をするのか? 処理するデータ量を減らす、処理にかかる時間を減らす→アテナやレッドシフトのコスト削減につながる

注意事項

無料利用枠を活用しているものの、一部課金が発生するサービスもあるので、その点ご注意ください。

また、普段使用しているAWSアカウント内で行う場合、ハンズオンで作っているリソースとわかるネーミングにして他のリソースと混在しないようご配慮ください。

ハンズオンの感想

具体的なハンズオンの内容はGithubの資料をご覧いただければと思いますが、実際にやってみた感想を書きたいと思います。

1.まだ触ったことのなかった、データ分析周りのサービスを色々触れた

  • EC2
  • S3
  • CloudWatch
  • CloudWatch Logs
  • Redshift
  • Redshift Spectrum
  • Athena
  • Glue
  • Elasticsearch Service
  • Kinesis Data Firehose
  • Quicksight
  • Fluentd

一部AWS以外のサービスもありますが、とにかく一度のハンズオンでとても多くのサービスを触ることができます。 個人的には、データ分析周りのRedshift、Elasticsearch Service、Athena、Glueなどなど触ったことないものばかりだったので、いい経験になりました。

2.試しに触るのにハードルの高いサービスも安心

データ分析系のサービスは、データありきなので、まずデータやログを生成するものがないと試しようがないということがあります。その点このハンズオンの場合、CloudFormationで一撃で作成される擬似アプリケーションが、ずっとそれらを生成し続けてくれるので、便利です。

また、Redshiftは立ち上げるのに勇気がいると感じてました。(データウェアハウスというからにはなんとなく大変そうというイメージ)。しかし、ハンズオンにはわかりやすく手順が明記されているので、安心感がありました。また、これはリアルな会場でやるメリットですが、ちょっとでも気になることがあればすぐにAWSJの方に質問できるというのも、安心要素でした。

データレイクを学ぶ動画

AWS Summit TOKYO で公開されたこの2本のセッションが、データレイクを学ぶには良さそうです。

座学メモ:ビッグデータ分析の考え方

座学でメモした内容は以下の通りです。

  • 従来のRDBを中心としたデータ分析
    • RDBを利用する利点
      • アクセスするツールが簡単、エコシステムが安定
      • スキーマが定義されている
      • トランザクション
      • データ型も強制できる
    • 課題1:入ってくるデータの質と量の変化
      • データの量が倍増どころか指数関数的伸び率で増えている
        • クエリするのも時間がかかるし、そもそも一つのDBで対応するのも困難
    • 課題2:スケーラビリティの限界がある
    • 課題3:非構造化データに対応しづらい
    • 課題4:リアルタイム分析や機械学習で活用しづらい
  • データのサイロ化
    • データによって扱うDBを変えようという考え
  • データのサイロ化の課題
    • スケーラビリティの課題は解決しない
      • 要求うが10倍になったらサイロ数が10倍になる
    • どこにどのデータがあるのかわからない
      • 途中で場所が変わったらさらにカオスに
    • サイロをまたいだ分析が困難
      • 同じデータを複数サイロに重複してもつとカオスも深刻化
  • そんな中で考え出されたのが、データレイク
  • DataLakeを中心としたデータ分析
    • 考えの骨子は「一旦貯める」「形を変えないで貯める」「とにかく貯める」
  • データレイクのメリット
    • ストレージと計算処理の分離
      • それぞれ独立してスケールでけいるので最適化しやすい
    • SSOT(Single Source Of Truth)
      • データレイクにあるものを正とすれば良い(どれが正しいの問題を解決)
    • 様々なinput/output手法に対応
      • in/outが独立、ETLやデータ処理エンジンを用途に合わせて利用
  • データレイクに必要なストレージ
    • 多様なデータを一箇所に保存
    • データを失わない
    • サイズ制限からの解放
    • 決められた方法(API)ですぐにアクセスできる
    • システム全体のハブ
    • →その上で最適なのが、S3
  • じゃあどうやって分析するの?
  • 前提:データ分析において唯一の万能なツールはない
  • 様々なツールの登場(Hadoop,Tableau,etc)
  • AWSのデータレイク - 大事:データ分析をうまく進めるには適切なツールやリソースを確保し、試行錯誤のサイクルを高速に回す
  • ラムダアーキテクチャ
    • 分析のリアルタイム性に対応するアーキテクチャ
    • ※AWS Lambdaのことではありません
    • 例えば、ログ管理について考えてみる
      • 多くのログが存在するが、それらをどう扱うのか。リアルタイムに欲しいものなのか、中長期的にためて使用するものなのか
      • それをうまく使い分けて分析しようとするのが、ラムダアーキテクチャ
    • ラムダアーキテクチャの構成要素
      • バッチレイヤ
      • サービングレイヤ
        • 中長期的に使用するものはこの二つを使用する
        • 例:売上実績
      • スピードレイヤ
        • リアルタイム処理が必要な方
        • 例:数分ごとにグラフが更新されるイメージ

終わりに

※会場には、DeepRacerの実機も追いてありました

ハンズオンはいいですね。今後もっといろんなものに首を突っ込んでみたいものです。

誰かのお役に立てば幸いです。それではまた。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.